DCon Solutions
Introduction
The DCon API provides the ability to actively control and protect the network, by disabling or limiting the capabilities of suspect devices.
In all three separate protection methods are provide through the DCon API
- Disable device
- Segment device
- Behaviourally limit the device.
Design considerations
All actions taken on a device use the DeviceID
to identify a distinct device. DeviceID
is a GUID, and abstract identifier that allows the API to use a stable ID to identify a device even if its IP address or MAC address changes.
The DCon API is defined using gRPC (like D3Events) in order to provide well defined interoperability
D3 interactions
It is possible to represent each API call as a signed D3 claim, signed by the DCon client entity, and where the claims map the the method and parameters called.
This technique is left open for future development, and could be useful when a DCon API is being called remotely and asynchronously, on one or more DCon servers.
API structure
The three complementary aspects of the DCon API
Disable device
This provides the ability to disable the device. Teh router will refuse to forward any connections from the disabled device.
Segment management
Segment management provides a coarse grained method to limit the cross talk between device types. It separates the network into distinct segments or pools. The APIs provide a method to add specific devices to segment, remove and move them.
Limited cross talk is sometimes needed. Take the example of discrete network segments for lighting, security and general purpose mobile and PC connection. The lighting system can be sensibly isolated from the security system. But there is a clear requirement for a user, or system administrators, mobile phone, which should default to the general purpose network, to have limited access to the lighting network, to both configure and control devices there. To that end the segment management also includes a bridging capability.
Behavioural management
The final method is the most sophisticated, and allows each devices to have fine grained restrictions, placed on it. A device with a known behaviour, can be restricted for example to only talk on certain ports to certain IP addresses.
Technically this is achieved by binding a unique device (identified by DeviceID) to a declared behaviour, defined by a set of MUD descriptors (https://datatracker.ietf.org/doc/html/rfc8520)